since unapply methods have to be kept around at runtime as well.

Calls to unapply are generated by the typer, so when would we need them to be kept at runtime? In fact, #8542 adds support for inline def unapply

Note that this could also allow us to support the implementation of an abstract method with an inline method

trait Hello:
  def hello: String

object App extends Hello:
  inline def hello: String = "hi"

I am not sure whether we need retained inline unapplys and whether they have to be user-level. @nicolasstucki do you have a typical usecase?

When trying to implement this PR, I noted a potential problem. It's in typeclass-derivation2b.scala, lines 52ff:

    inline override def alternative(inline n: Int) <: GenericProduct[_ <: Lst[T]] =
      inline n match {
        case 0 => Cons.GenericCons[T]
        case 1 => Nil.GenericNil

If we translate that with the described scheme, we get:

53 |      inline n match {
   |             ^
   |             cannot reduce inline match with
   |              scrutinee:  {
   |               n
   |             } : (n : Int)
   |              patterns :  case 0
   |                          case 1

The problem is that the retained version of alternative does not have parameters that are constant, so the inline match fails.

I see two feasible ways around this

• Make inline override methods that have inline parameters not retained, i.e. use the old scheme for them.
  This works, but feels very subtle and implicit.

• Invent some more explicit scheme for inline methods to simply shadow other methods, but not override them at runtime. One such possibility would be to bring back erased. E.g. we could reformulate alternative like this:

    inline erased override def alternative(inline n: Int) <: GenericProduct[_ <: Lst[T]] = ...

An erased override is not an override at runtime, only at compile time. So no runtime instance of alternative needs to be created.

Opinions?

@odersky The problematic example has a very specific property: the overridden method is never actually correct to begin with. It has = ??? as its rhs, which turns out fine because it's never called at runtime. It should be abstract to begin with, and would certainly be anyway if that had been allowed like we suggest.

Moreover, the example clearly shows that it can only work if that method is overridden in the "virtual" dispatch when it is called. It's just that this always happens statically. Again, this highlights that the true overriding semantics is what this example relies on.

What we need is therefore not a way to bypass overriding semantics with an erased at overriding site. Instead we need a way to mark a method as available for a call, but at compile time it must be checked that it is statically overridden at every call site. That would be the meaning of an abstract inline def, from what I can see.

I would therefore like to declare GenericSum.alternative as an abstract inline def, and GenericLst.alternative as a normal concrete inline def (which would not get a runtime bridge because it only implements an abstract inline method; not because itself is marked as a semantically wrong inline erased thing).

I see two feasible ways around this

I'm not a fan of either way, seems like too much complexity for too little gains. I think it's OK to have stricter requirements for the bodies of inline override def than inline def.

I am not sure if the inline override def unapply is needed. I will investigate further.

The code for inline override def alternative does not look problematic as one should just change the implementation to

 inline override def alternative(inline n: Int) <: GenericProduct[_ <: Lst[T]] =
     n match { // remove the inline here
        case 0 => Cons.GenericCons[T]
        case 1 => Nil.GenericNil

This means that if the code is not inlined, the match will be retained. If the code is inlined, it will reduce the match.

Alternatively, we could say the inline match does not check the body of the override inline.

Another alternative is to write the code as follows

 inline override def alternative(inline n: Int) <: GenericProduct[_ <: Lst[T]] =
     inline n match
        case 0 => Cons.GenericCons[T]
        case 1 => Nil.GenericNil
        case _ =>
            // non-specialized implementation (not necessarily the same as the inlined code)
            n match
              case 0 => Cons.GenericCons[T]
              case 1 => Nil.GenericNil

@sjrd Good analysis. I think abstract inline could be the way to go here. I'll try that next.

Will this have any effect over the ability to combine inline def with opaque type?
lampepfl/dotty-feature-requests#82

@soronpo No it won't, neither positively nor negatively.